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Enrollment over Secure Transport 


Abstract 


This document profiles certificate enrollment for clients using 
Certificate Management over CMS (CMC) messages over a secure 
transport. This profile, called Enrollment over Secure Transport 
(EST), describes a simple, yet functional, certificate management 
protocol targeting Public Key Infrastructure (PKI) clients that need 
to acquire client certificates and associated Certification Authority 
(CA) certificates. It also supports client-generated public/private 
key pairs as well as key pairs generated by the CA. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7030. 
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1. Introduction 


This document profiles certificate enrollment for clients using 
Certificate Management over CMS (CMC) [RFC5272] messages over a 
secure transport. Enrollment over Secure Transport (EST) describes 
the use of Transport Layer Security (TLS) 1.1 [RFC4346], 1.2 
[RFC5246], or any future version) and Hypertext Transfer Protocol 
(HTTP) [RFC2616] to provide an authenticated and authorized channel 
for Simple Public Key Infrastructure (PKI) Requests and Responses 
[RFC5272]. 


Architecturally, the EST service is located between a Certification 
Authority (CA) and a client. It performs several functions 
traditionally allocated to the Registration Authority (RA) role in a 
PKI. The nature of communication between an EST server and a CA is 
not described in this document. 
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EST adopts the Certificate Management Protocol (CMP) [RFC4210] model 
for CA certificate rollover, but it does not use the CMP message 
syntax or protocol. EST servers are extensible in that new functions 
may be defined to provide additional capabilities not specified in 
CMC [RFC5272], and this document defines two such extensions: one for 
requesting Certificate Signing Request attributes and another for 
requesting server-generated keys. 


EST specifies how to transfer messages securely via HTTP over TLS 
(HTTPS) [RFC2818], where the HTTP headers and media types are used in 
conjunction with TLS. HTTPS operates over TCP; this document does 
not specify EST over HTTP/Datagram Transport Layer Security/User 
Datagram Protocol (HTTP/DTLS/UDP). With a suitable specification for 
combining HTTP, DTLS, and UDP, there are no EST requirements that 
would prevent it from working over such a stack. Figure 1 shows how 
the layers build upon each other. 


EST Layering: 


Protocols: 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 
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It is assumed that the reader is familiar with the terms and concepts 
described in Public Key Cryptography Standard (PKCS) 410 [RFC2986], 
HTTPS [RFC2818], CMP [RFC4210], CMC [RFC5272] [RFC5273] [RFC5274], and 
TLS [RFC4346]. 


In addition to the terms defined in the terminology section of CMC 
[RFC5272], the following terms are defined for clarity: 


EST CA: For certificate issuing services, the EST CA is reached 
through the EST server; the CA could be logically "behind" the EST 
server or embedded within it. 


Third-Party Trust Anchor: Any trust anchor (TA) that is not 
authoritative for the PKI hierarchy for which the EST server is 
providing services. 


Explicit Trust Anchor: Any TA that is explicitly configured on the 
client or server for use during EST TLS authentication; for 
example, a TA that is manually configured on the EST client or 
bootstrapped as described in Section 4.1.1. (See more details in 
Sections 3.6 and 6.) 


Implicit Trust Anchor: Any third-party TA that is available on the 
client or server for use during TLS authentication but is not 
specifically indicated for use during EST TLS authentication; for 
example, TAs commonly used by web browsers to authenticate web 
servers or TAs used by servers to authenticate manufacturer- 
installed client credentials (such as certificates populated into 
cable modems or routers in the factory). The authorization model 
for these TAs is different from the authorization model for 
Explicit Trust Anchors. (See more details in Sections 3.6.1, 
3.6.2, and 6). 


Certificate-Less TLS:  Certificate-less TLS cipher suites provide a 
way to perform mutual authentication in situations where neither 
the client nor server have certificates or are willing to use 
them. The credential used for authentication is a word, phrase, 
code, or key that is shared between the client and server. The 
credential must be uniquely shared between the client and server 
in order to provide authentication of an individual client to an 
individual server. 


2. Operational Scenario Overviews 


This section provides an informative overview of the operational 
scenarios to better introduce the reader to the protocol discussion. 
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Both the EST clients and server are configured with information that 
provides the basis for mutual authentication and for authorization. 
The specific initialization data depends on the methods available in 
the client and server, but it can include shared secrets, network 
service names and locations (e.g., a Uniform Resource Identifier 
(URI) [RFC3986]), trust anchor information (e.g., a CA certificate or 
a hash of a TA's certificate), and enrollment keys and certificates. 
Depending on an enterprise's acquisition and network management 
practices, some initialization may be performed by the vendor prior 
to delivery of client hardware and software. In that case, the 
client vendor may provide data, such as trust anchors, to the 
enterprise via a secure procedure. The distribution of this initial 
information is out of scope. 


Distribution of trust anchors and other certificates can be effected 
via the EST server. However, nothing can be inferred about the 
authenticity of this data until an out-of-band mechanism is used to 
verify them. 


Sections 2.1-2.3 very closely mirror the text of the Scenarios 
Appendix of [RFC6403] with such modifications as are appropriate for 
this profile. Sections 2.1-2.6, below, enumerate the set of EST 
functions (see Figure 5) and provide an informative overview of EST's 
capabilities. 


The general client/server interaction proceeds as follows: 


The client initiates a TLS-secured HTTP session with an EST 
server. 


A specific EST service is requested based on a portion of the URI 
used for the session. 


The client and server authenticate each other. 


The client verifies that the server is authorized to serve this 
client. 


The server verifies that the client is authorized to make use of 
this server and the request that the client has made. 


The server acts upon the client request. 
Obtaining CA Certificates 
The EST client can request a copy of the current EST CA 


certificate(s) from the EST server. The EST client is assumed to 
perform this operation before performing other operations. 
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Throughout this document we assume the EST CA has a certificate that 
is used by the client to verify signed objects issued by the CA, 
e.g., certificates and certificate revocation lists (CRLs), and that 
a different certificate than the one used to verify signatures on 
certificates and CRLs is used when EST protocol communication 
requires additional encryption. 


The EST client authenticates and verifies the authorization scope of 
the EST server when requesting the current CA certificate(s). As 
detailed in Sections 3.3.1 and 3.3.3, available options include: 


o Verifying the EST server's HTTPS URI against the EST server's 
certificate using Implicit TAs (similar to a common HTTPS 
exchange). This allows the EST server and client to leverage 
existing TAs that might be known to the EST client. 


o The client can leverage a previously distributed trust anchor 
Specific to the EST server. This allows the EST client to use an 
existing, potentially older, CA certificate to request a current 
CA certificate. 


o For bootstrapping, the EST client can rely upon manual 
authentication performed by the end-user as detailed in 
Section 4.1.1. 


o The client can leverage the binding of a shared credential to a 
Specific EST server with a certificate-less TLS cipher suite. 


Client authentication is not required for this exchange, so it is 
trivially supported by the EST server. 


2525 Initial Enrollment 


After authenticating an EST server and verifying that it is 
authorized to provide services to the client, an EST client can 
acquire a certificate for itself by submitting an enrollment request 
to that server. 


The EST server authenticates and authorizes the EST client as 
Specified in Sections 3.3.2, 3.3.3, and 3.7. The methods described 
in the normative text that are discussed in this overview include: 


o TLS with a previously issued client certificate (e.g., an existing 
certificate issued by the EST CA); 


o TLS with a previously installed certificate (e.g., manufacturer- 


installed certificate or a certificate issued by some other 
party); 
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o Certificate-less TLS (e.g., with a shared credential distributed 
out-of-band); 


o HTTP-based with a username/password distributed out-of-band. 
2.2.1. Certificate TLS Authentication 


If the EST client has a previously installed certificate issued by a 
third-party CA, this certificate can be used to authenticate the 
client's request for a certificate from the EST server (if that CA is 
recognized by the EST server). An EST client responds to the EST 
server's TLS certificate request message with the existing 
certificate already held by the client. The EST server will verify 
the client's existing certificate and authorize the client's request 
as described in Section 3.3.2. 


2.2.2. Certificate-Less TLS Authentication 


The EST client and EST server can be mutually authenticated using a 
certificate-less TLS cipher suite (see Section 3.3.3). 


2.2.3.  HTTP-Based Client Authentication 


The EST server can optionally also request that the EST client submit 
a username/password using the HTTP Basic or Digest authentication 
methods (see Section 3.2.3). This approach is desirable if the EST 
client cannot be authenticated during the TLS handshake (see 

Section 3.3.2) or the EST server policy requires additional 
authentication information; see Section 3.2.3. In all cases, 
HTTP-based client authentication is only to be performed over a 
TLS-protected transport (see Section 3.3). 


2.3. Client Certificate Reissuance 


An EST client can renew/rekey its existing client certificate by 
submitting a re-enrollment request to an EST server. 


When the current EST client certificate can be used for TLS client 
authentication (Section 3.3.2), the client presents this certificate 
to the EST server for client authentication. When the to be reissued 
EST client certificate cannot be used for TLS client authentication, 
any of the authentication methods used for initial enrollment can be 
used. 


For example, if the client has an alternative certificate issued by 


the EST CA that can be used for TLS client authentication, then it 
can be used. 
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The certificate request message includes the same Subject and 
SubjectAltName as the current certificate. Name changes are 
requested as specified in Section 4.2.2. 


2.4. Server Key Generation 


The EST client can request a server-generated certificate and key 
pair (see Section 4.4). 


2.5. Full PKI Request Messages 


Full PKI Request [RFC5272] messages can be transported via EST using 
the Full CMC Request function. This affords access to functions not 
provided by the Simple Enrollment functions. Full PKI Request 
messages are defined in Sections 3.2 and 4.2 of [RFC5272]. See 
Section 4.3 for a discussion of how EST provides a transport for 
these messages. 


2.6. Certificate Signing Request (CSR) Attributes Request 


Prior to sending an enrollment request to an EST server, an EST 
client can query the EST server for a set of additional attributes 
that the client is requested to use in a subsequent enrollment 
request. 


These attributes can provide additional descriptive information that 
the EST server cannot access itself, such as the Media Access Control 
(MAC) address of an interface of the EST client. Alternatively, 
these attributes can indicate the kind of enrollment request, such as 
a specific elliptic curve or a specific hash function that the client 
is expected to use when generating the CSR. 


Pritikin, et al. Standards Track [Page 9] 


RFC 7030 


EST 


3. Protocol Design and Layering 


Figure 2 provides an expansion of Figure 1, 
are used. 


that follow. 


EST Layering: 


Protocols and uses: 


+ 
| 
| 
| 
| 
| 
| 
| 


Message types: 


"Simple PKI" messages 

(incorporates proof-of-possession) 

CA certificate retrieval 

"Full PKI" messages (OPTIONAL) 
(incorporates proof-of-possession) 

CSR Attributes Request (OPTIONAL) 
Server-generated key request (OPTIONAL) 


HTTP: 


HTTP headers and URIs for control 
- Content-Type headers specify message type 
- Headers for control/error messages 
- URIs for selecting functions 

Basic or Digest authentication (OPTIONAL) 


for transport security: 

Authentication of the EST server 
Authentication of the EST client (OPTIONAL) 
Provides communications integrity 

and confidentiality 


Supplies channel-binding [RFC5929] information 


to link proof-of-identity with message-based 
proof-of-possession (OPTIONAL) 


Figure 2 


October 2013 


describing how the layers 
Each aspect is described in more detail in the sections 


Specifying HTTPS as the secure transport for enrollment messages 
introduces two "layers" to communicate authentication and control 
messages: TLS and HTTP. 
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The TLS layer provides integrity and confidentiality during 
transport. The proof-of-identity is supplied by TLS handshake 
authentication and optionally also by the HTTP layer headers. The 
message type and control/error messages are included in the HTTP 
headers. 


CMC ([RFC5272], Section 3.1) notes that "the Simple PKI Request MUST 
NOT be used if a proof-of-identity needs to be included". Since the 
TLS and HTTP layers can provide proof-of-identity for EST clients and 
servers, the Simple PKI message types are used. 


The TLS layer certificate exchange provides a method for authorizing 
client enrollment requests using existing certificates. Such 
certificates may have been issued by the CA (from which the client is 
requesting a certificate), or they may have been issued under a 
distinct PKI (e.g., an IEEE 802.1AR Initial Device Identifier 
(IDevID) [IDevID] credential). 


Proof-of-possession (POP) is a distinct issue from proof-of-identity 
and is included in the Simple PKI message type as described in 
Section 3.4. A method of linking proof-of-identity and 
proof-of-possession is described in Section 3.5. 


This document also defines transport for CMC [RFC5272] that complies 
with the CMC Transport Protocols [RFC5273]. CMC's POP and 
proof-of-identity mechanisms are defined in CMC, but the mechanisms 
here can also be used in conjunction with those mechanisms in "Full 
PKI" messages. 


During protocol exchanges, different certificates can be used. The 
following table provides an informative overview.  End-entities can 
have one or more certificates of each type listed in Figure 3 and use 
one or more trust anchor databases of each type listed in Figure 4. 
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their corresponding uses: 


4-------------- yaa Se Se Se Se E ER UP C c E E dE er m E E EE * 

| Certificate | Issuer | Use and section references 

* * * 

| EST server | The CA served by | Presented by the EST server 

| certificate | the EST server | during the TLS handshake. 

| | 

| | | Section 3.3.1 

4-------------- 4-------------------- HeSsss Sse SSS se SS SSS 5 SS SS SSS sS== 

| EST server | ACA | Presented by the EST server 

| certificate | authenticatable by | during the TLS handshake. 

| | a third-party TA, | 

| | e.g., a web server | Section 3.3.1 and 

| | ca | Security Considerations 

panenn prassa O N a 
Third-party A CA Presented by the EST client 


EST client 
certificate 


EST client 
certificate 


End-entity 
certificate 


+ —— c 4 —— 


Pritikin, et al. 


authenticatable by 
a third-party TA, 
e.g., a device 
manufacturer 

The CA served by 
the EST server 


+ ——— 


The CA served by 
the EST server 


+ —— 4+ —— 


Standards Track 


to the EST server by clients 
that have not yet enrolled. 


Section 3.3.2 


Presented to the EST server 


during future EST operations. 


Section 3.3.2 


Clients can obtain certs 
that are intended for 
non-EST uses. This includes 
certs that cannot be used 
for EST operations. 


Section 4.2.3 
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Trust anchor databases and their corresponding uses: 


TA database Use and section references 


EST server 
Explicit 
TA database 


certificates issued by the EST CA, including EST 
client certificates during enroll/re-enroll 


+ 
| 
+ 
| 
| 
| 
| operations. 


| 
+ 
EST servers use this TA database to authenticate | 
| 
| 
| 


Section 3.3.2 


4-------------- DPI E CI EE RE * 

| EST server | EST servers use this TA database to authenticate | 

| Implicit | certificates issued by third-party TAs; | 

| TA database | e.g., EST client certificates issued by a device | 

| | manufacturer. | 

| | An Implicit TA database can be disabled. 

| | Section 3.3.2 | 

RERO E ss + 

| EST client | EST clients use this TA database to authenticate | 

| Explicit | certificates issued by the EST CA, including EST | 

| TA database | server certificates. 

| | Sections 3.1, 3.3.1, 3.6.1, and 4.1.1 | 

PaA EN sn + 

| EST client | EST clients use this TA database to | 

| Implicit | authenticate an EST server that uses an externally | 
TA database | issued certificate. 

| An Implicit TA database can be disabled. 

| | 

| | Sections 3.1, 3.3.1, 3.6.2, and 

| | Security Considerations 

E A E R-—-------------------------------------------------- * 

Figure 4 


3.1. Application Layer 


The EST client MUST be capable of generating and parsing Simple PKI 
messages (see Section 4.2). Generating and parsing Full PKI messages 
is OPTIONAL (see Section 4.3). The client MUST also be able to 
request CA certificates from the EST server and parse the returned 
"bag" of certificates (see Section 4.1). Requesting CSR attributes 
and parsing the returned list of attributes is OPTIONAL (see 

Section 4.5). 
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Details of the EST client application configuration are out of scope 
of the protocol discussion but are necessary for understanding the 
prerequisites of initiating protocol operations. The EST client is 
RECOMMENDED to be configured with TA databases for Section 3.3.1 or 
with a secret key for Section 3.3.3.  Implementations conforming to 
this standard MUST provide the ability to designate Explicit TAs. 
For human usability reasons, a "fingerprint" of an Explicit TA 
database entry can be configured for bootstrapping as discussed in 
Section 4.1.1. Configuration of an Implicit TA database, perhaps by 
its inclusion within the EST client distribution or available from 
the operating system, provides flexibility along with the caveats 
detailed in Section 6.  Implementations conforming to this standard 
MUST provide the ability to disable use of any Implicit TA database. 


The EST client is configured with sufficient information to form the 
EST server URI. This can be the full operation path segment (e.g., 
https://www.example.com/.well-known/est/ or 
https://www.example.com/.well-known/est/arbitraryLabell), or the EST 
client can be configured with a tuple composed of the authority 
portion of the URI along with the OPTIONAL label (e.g., 
"www.example.com:80" and "arbitraryLabell") or just the authority 
portion of the URI. 


3.2. HTTP Layer 


HTTP is used to transfer EST messages.  URIS are defined for handling 
each media type (i.e., message type) as described in Section 3.2.2. 
HTTP is also used for client authentication services when TLS client 
authentication is not available, due to the lack of a client 
certificate suitable for use by TLS (see Section 3.2.3). HTTP 
authentication can also be used in addition to TLS client 
authentication if the EST server wishes additional authentication 
information, as noted in Section 2.2.3. Registered media types are 
used to convey EST messages as specified in Figure 6. 


HTTP 1.1 [RFC2616] and above support persistent connections. As 
described in Section 8.1 of RFC 2616, persistent connections may be 
used to reduce network and processing loads associated with multiple 
HTTP requests. EST does not require or preclude persistent HTTP 
connections. 
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3.2.1. HTTP Headers for Control 


The HTTP Status value is used to communicate success or failure of an 
EST function. HTTP authentication is used by a client when requested 
by the server. 


The media types specified in the HTTP Content-Type header indicate 
which EST message is being transferred. Media types used by EST are 
Specified in Section 3.2.4. 


HTTP redirections (3xx status codes) to the same web origin (see 
[RFC6454]) SHOULD be handled by the client without user input so long 
as all applicable security checks (Sections 3.3 and 3.6) have been 
enforced on the initial connection. The client initiates a new TLS 
connection and performs all applicable security checks when 


redirected to other web origin servers.  Redirections to other web 
origins require the EST client to obtain user input for non-GET or 
HEAD requests as specified in [RFC2616]. Additionally, if the client 


has already generated a CSR that includes linking identity and POP 
information (Section 3.5), then the CSR will need to be recreated to 
incorporate the tls-unique from the new, redirected session. Note: 
the key pair need not be regenerated. These are processing and 
interface burdens on the client. EST server administrators are 
advised to take this into consideration. 
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3.2.2. HTTP URIs for Control 


The EST server MUST support the use of the path-prefix of "/.well- 
known/" as defined in [RFC5785] and the registered name of "est". 
Thus, a valid EST server URI path begins with 
"https://www.example.com/.well-known/est". Each EST operation is 
indicated by a path-suffix that indicates the intended operation: 


Operations and their corresponding URIs: 


R-—---------------------- R-—--------------- 4R-—----------------- * 
| Operation [Operation path | Details 
* * * * 
| Distribution of CA | /cacerts | Section 4.1 
| Certificates (MUST) | | | 
a T o E t--- N E + 

Enrollment of /simpleenroll Section 4.2 

Clients (MUST) 
n P E A E A E OEE H EA RE + 
| Re-enrollment of | /simplereenroll | Section 4.2.2 
| Clients (MUST) | | | 
S E EEA OE peene E EAN E NET + 
| Full CMC (OPTIONAL) | /fullemc | Section 4.3 | 
teases Saas See sae a Sess qTunceszilclaonccunclcg 4R------------------- * 
| Server-Side Key | /serverkeygen | Section 4.4 
| Generation (OPTIONAL) | | | 
A 555 E A A T N - === + 
| CSR Attributes | /csrattrs | Section 4.5 
| (OPTIONAL) | | | 
E E e E E A E A E E + 

Figure 5 


The operation path (Figure 5) is appended to the path-prefix to form 
the URI used with HTTP GET or POST to perform the desired EST 
operation. An example valid URI absolute path for the "/cacerts" 
operation is "/.well-known/est/cacerts". To retrieve the CA's 
certificates, the EST client would use the following HTTP 
request-line: 


GET /.well-known/est/cacerts HTTP/1.1 


Likewise, to request a new certificate in this example scheme, the 
EST client would use the following request-line: 


POST /.well-known/est/simpleenroll HTTP/1.1 
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The use of distinct operation paths simplifies implementation for 
servers that do not perform client authentication when distributing 
/cacerts responses. 


An EST server MAY provide service for multiple CAs as indicated by an 
OPTIONAL additional path segment between the registered application 
name and the operation path. To avoid conflict, the CA label MUST 
NOT be the same as any defined operation path segment. The EST 
server MUST provide services regardless of whether the additional 


path segment is present. The following are three example valid URIs: 
1. https://www.example.com/.well-known/est/cacerts 

2. https://www.example.com/.well-known/est/arbitraryLabell/cacerts 
3. https://www.example.com/.well-known/est/arbitraryLabel2/cacerts 


In this specification, the distinction between enroll and renew/rekey 
is explicitly indicated by the HTTP URI. When requesting /fullcmc 
operations, CMC [RFC5272] uses the same messages for certificate 
renewal and certificate rekey. 


An EST server can provide additional services using other URIs. 
3.2.3. HTTP-Based Client Authentication 


The EST server MAY request HTTP-based client authentication. This 
request can be in addition to successful TLS client authentication 
(Section 3.3.2) if EST server policy requires additional 
authentication. (For example, the EST server may require that an EST 
client "knows" a password in addition to "having" an existing client 
certificate.) Or, HTTP-based client authentication can be an EST 
server policy-specified fallback in situations where the EST client 
did not successfully complete the TLS client authentication. (This 
might arise if the EST client is enrolling for the first time or if 
the certificates available to an EST client cannot be used for TLS 
client authentication.) 


HTTP Basic and Digest authentication MUST only be performed over TLS 
1.1 [RFC4346] or later versions. NULL and anon cipher suites MUST 
NOT be used because they do not provide confidentiality or support 
mutual certificate-based or certificate-less authentication, 
respectively. As specified in "Certificate Management over CMS 
(CMC): Transport Protocols" [RFC5273], the server "MUST NOT assume 
client support for any type of HTTP authentication such as cookies, 
Basic authentication, or Digest authentication". Clients SHOULD 
support the Basic and Digest authentication mechanism. 
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Servers that wish to use Basic and Digest authentication reject the 
HTTP request using the HTTP-defined WWW-Authenticate response-header 
([REC2616], Section 14.47). The client is expected to retry the 
request, including the appropriate Authorization Request header 
([RFC2617], Section 3.2.2), if the client is capable of using the 
Basic or Digest authentication. If the client is not capable of 
retrying the request or it is not capable of Basic or Digest 
authentication, then the client MUST terminate the connection. 


A client MAY set the username to the empty string ("") if it is 
presenting a password that is not associated with a username. 


Support for HTTP-based client authentication has security 
ramifications as discussed in Section 6. The client MUST NOT respond 
to the server's HTTP authentication request unless the client has 
authorized the EST server (as per Section 3.6). 
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3.2.4. Message Types 


This document uses existing media types for the messages as specified 
by FTP and HTTP [RFC2585], application/pkcs10 [RFC5967], and CMC 
[RFC5272]. 


For consistency with [RFC5273], each distinct EST message type uses 
an HTTP Content-Type header with a specific media type. 


The EST messages and their corresponding media types for each 
operation are: 


+—-------------------- +—-------------------------- 4+—------------------- + 
| Message type | Request media type | Request section(s) | 
| | Response media type(s) | Response section | 
| (per operation) | Source(s) of types | 
+ + + + 
| Distribution of CA | N/A | Section 4.1 | 
| Certificates | application/pkcs7-mime | Section 4.1.1 
| | [RFC5751] | | 
| /cacerts | | 
4+—-------------------- 4+-------------------------- 4+------------------- + 
| Client Certificate | application/pkcs10 | Sections 4.2/4.2.1| 
| Request Functions | application/pkcs7-mime | Section 4.2.2 | 
| | [RFC5967] [RFC5751] | | 
| /simpleenroll | | | 
| /simplereenroll | | | 
4+-------------------- 4+—-------------------------- 4+------------------- + 
| Full CMC | application/pkcs7-mime | Section 4.3.1 
| | application/pkcs7-mime | Section 4.3.2 | 
| /fulleme | [RFC5751] | | 
+—-------------------- 4+—-------------------------- 4+—------------------- + 
| Server-Side Key | application/pkcs10 | Section 4.4.1 
| Generation | multipart/mixed | Section 4.4.2 
(application/pkcs7-mime & 
| | application/pkcs8) | | 
| | [RFC5967] [RFC5751] | | 
| /serverkeygen | [RFC5958] | 
4+—-------------------- 4+—-------------------------- 4+—------------------- + 
CSR Attributes N/A Section 4.5.1 


application/csrattrs Section 4.5.2 
(This document) 
| /csrattrs 


| 
| 
4+-------------------- 4+-------------------------- 


+ — 
l 
| 
| 
| 
| 
l 
| 
| 
| 
| 
l 
| 
| 
l 
l 
l 
| 
+ 
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3.3. TLS Layer 


TLS provides authentication, which in turn enables authorization 
decisions. The EST server and EST client are responsible for 
ensuring that an acceptable cipher suite is negotiated and that 
mutual authentication has been performed.  TLS authentication is most 
commonly enabled with the use of certificates [RFC5280]. 

Alternately, certificate-less TLS authentication, where neither the 
client nor server present a certificate, is also an acceptable method 
for EST mutual authentication (Section 3.3.3). The EST server MUST 
be authenticated during the TLS handshake unless the client is 
requesting Bootstrap Distribution of CA certificates (Section 4.1.1) 
or Full CMC (Section 4.3). 


HTTPS [RFC2818] specifies how HTTP messages are carried over TLS. 
HTTPS MUST be used. TLS 1.1 [RFC4346] (or a later version) MUST be 
used for all EST communications.  TLS session resumption [RFC5077] 
SHOULD be supported. 


TLS channel-binding information can be inserted into a certificate 
request, as detailed in Section 3.5, in order to provide the EST 
server with assurance that the authenticated TLS client has access to 
the private key for the certificate being requested. The EST server 
MUST implement Section 3.5. 


3.3.1.  TLS-Based Server Authentication 
TLS server authentication with certificates MUST be supported. 
The EST client authenticates the EST server as defined for the cipher 
suite negotiated. The following text provides details assuming a 


certificate-based cipher suite, such as the TLS 1.1 [RFC4346] 
mandatory cipher suite (TLS RSA WITH 3DES EDE CBC SHA). 


Certificate validation MUST be performed as per [RFC5280]. The EST 
server certificate MUST conform to the [RFC5280] certificate profile. 


The client validates the TLS server certificate using the EST client 
Explicit and, if enabled, Implicit TA database(s). The client MUST 
maintain a distinction between the use of Explicit and Implicit TA 
databases during authentication in order to support proper 
authorization. The EST client MUST perform authorization checks as 
Specified in Section 3.6. 


If certificate validation fails, the client MAY follow the procedure 


outlined in Section 4.1.1 for Bootstrap Distribution of CA 
certificates. 
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3.3.2.  TLS-Based Client Authentication 


TLS client authentication is the RECOMMENDED method for identifying 
EST clients.  HTTP-based client authentication (Section 3.2.3) MAY be 
used. 


The EST server authenticates the EST client as defined for the cipher 
suite negotiated. The following text provides details assuming a 
certificate-based cipher suite such as the TLS 1.1 [RFC4346] 
mandatory cipher suite (TLS RSA WITH 3DES EDE CBC SHA). The EST 
server MUST support certificate-based client authentication. 


Generally, the client will use an existing certificate for renew or 
rekey operations. If the certificate to be renewed or rekeyed is 
appropriate for the negotiated cipher suite, then the client MUST use 
it for the TLS handshake, otherwise the client SHOULD use an 
alternate certificate that is suitable for the cipher suite and 
contains the same subject identity information. When requesting an 
enroll operation, the client MAY use a client certificate issued by a 
third party to authenticate itself. 


Certificate validation MUST be performed as per [RFC5280]. The EST 
client certificate MUST conform to the [RFC5280] certificate profile. 


The server validates the TLS client certificate using the EST server 
Explicit and, if enabled, Implicit TA database(s). The server MUST 
maintain a distinction between the use of Explicit and Implicit TA 
databases during authentication in order to support proper 
authorization. 


The EST server MUST perform authorization checks as specified in 
Section 3.7. 


If a client does not support TLS client authentication, then it MUST 
support HTTP-based client authentication (Section 3.2.3) or 
certificate-less TLS authentication (Section 3.3.3). 


3.3.3. Certificate-Less TLS Mutual Authentication 
Certificate-less TLS cipher suites provide a way to perform mutual 


authentication in situations where neither the client nor server have 
certificates, do not desire to use certificates, or do not have the 


trust anchors necessary to verify a certificate. The client and 
server MAY negotiate a certificate-less cipher suite for mutual 
authentication. 


When using certificate-less mutual authentication in TLS for 
enrollment, the cipher suite MUST be based on a protocol that is 
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resistant to dictionary attack and MUST be based on a zero knowledge 
protocol. Transport Layer Security-Secure Remote Password (TLS-SRP) 
cipher suites, i.e., those with _SRP_ in the name, listed in 

Section 2.7 of [RFC5054] are suitable for this purpose. Section 6 
lists the characteristics of a cipher suite that are suitable for use 
in certificate-less mutual authentication for enrollment. 


Successful authentication using a certificate-less cipher suite 
proves knowledge of a pre-shared secret that implicitly authorizes a 
peer in the exchange. 


3.4.  Proof-of-Possession 


As defined in Section 2.1 of CMC [RFC5272], proof-of-possession (POP) 
"refers to a value that can be used to prove that the private key 
corresponding to the public key is in the possession of and can be 
used by an end-entity". 


The signed enrollment request provides a signature-based 
proof-of-possession. The mechanism described in Section 3.5 
strengthens this by optionally including "Direct"-based 
proof-of-possession [RFC5272] by including TLS session-specific 
information within the data covered by the enrollment request 
signature (thus linking the enrollment request to the authenticated 
end point of the TLS connection). 


3.5. Linking Identity and POP Information 


Server policy will determine whether clients are required to use the 
mechanism specified in this section. This specification provides a 
method of linking identity and proof-of-possession by including 
information specific to the current authenticated TLS session within 
the signed certification request. The client can determine if the 
server requires the linking of identity and POP by examining the CSR 
Attributes Response (see Section 4.5.2). Regardless of the CSR 
Attributes Response, clients SHOULD link identity and POP by 
embedding tls-unique information in the certification request. If 
tls-unique information is included by the client, the server MUST 
verify it. The EST server MAY reject requests without tls-unique 
information as indicated by server policy. 


Linking identity and proof-of-possession proves to the server that 
the authenticated TLS client has possession of the private key 
associated with the certification request, and that the client was 
able to sign the certification request after the TLS session was 
established. This is an alternative to the "Linking Identity and POP 
Information" method defined by Section 6 of [RFC5272] that is 
available if Full PKI messages are used. 
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The client generating the CSR obtains the tls-unique value from the 
TLS subsystem as described in Channel Bindings for TLS [RFC5929]. 

The EST client operations between obtaining the tls-unique value 
through generation of the CSR that contains the current tls-unique 
value and the subsequent verification of this value by the EST server 
are the "phases of the application protocol during which application- 
layer authentication occurs"; these operations are protected by the 
synchronization interoperability mechanism described in the "Channel 
Bindings for TLS" interoperability notes in Section 3.1 of [RFC5929]. 


When performing renegotiation, TLS "secure renegotiation" [RFC5746] 
MUST be used. 


The tls-unique value is base64 encoded as specified in Section 4 of 
[RFC4648], and the resulting string is placed in the certification 
request challenge-password field ([RFC2985], Section 5.4.1). The 
challenge-password field is limited to 255 bytes (Section 7.4.9 of 
[RFC5246] indicates that no existing cipher suite would result in an 
issue with this limitation). If the challenge-password attribute is 
absent, the client did not include the optional channel-binding 
information (the presence of the challenge-password attribute 
indicates the inclusion of tls-unique information). 


If the EST server makes use of a back-end infrastructure for 
processing, it is RECOMMENDED that the results of this verification 
be communicated. (For example, this communication might use the CMC 
[RFC5272] "RA POP Witness Control" in a CMC Full PKI Request message. 
Or, an EST server might TLS-authenticate an EST client as being a 
trusted infrastructure element that does not forward invalid 
requests. A detailed discussion of back-end processing is out of 
scope.) 


When rejecting requests, the EST server response is as described for 
all enroll responses (Section 4.2.3). If a Full PKI Response is 
included, the CMCFailInfo MUST be set to popFailed. If a human- 
readable reject message is included, it SHOULD include an informative 
text message indicating that the linking of identity and POP 
information is required. 


3.6. Server Authorization 


The client MUST check EST server authorization before accepting any 
Server responses or responding to HTTP authentication requests. 


The EST client authorization method depends on which method was used 
to authenticate the server. When the Explicit TA database is used to 
authenticate the EST server, then Section 3.6.1 applies. When the 
Implicit TA database is used to authenticate the EST server, then 
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Section 3.6.2 applies. Successful authentication using a 
certificate-less cipher suite implies authorization of the server. 


The client MAY perform bootstrapping as specified in Section 4.1.1 
even if these checks fail. 


3.6.1. Client Use of Explicit TA Database 


When the EST client Explicit TA database is used to validate the EST 
server certificate, the client MUST check either the configured URI 
or the most recent HTTP redirection URI against the server's identity 
according to the rules specified in [RFC6125], Section 6.4, or the 
EST server certificate MUST contain the id-kp-cmcRA [RFC6402] 
extended key usage extension. 


3.6.2. Client Use of Implicit TA Database 


When the EST client Implicit TA database is used to validate the EST 
server certificate, the client MUST check the configured URI and each 
HTTP redirection URI according to the rules specified in [RFC6125], 
Section 6.4. The provisioned URI or the most recent HTTP redirection 
URI provides the basis for authorization, and the server’s 
authenticated identity confirms it is the authorized server. 


3.7. Client Authorization 


The decision to issue a certificate to a client is always controlled 
by local CA policy. The EST server configuration reflects this CA 
policy. This document does not specify any constraints on such 
policy. EST provides the EST server access to each client’s 
authenticated identity -- e.g., the TLS client’s certificate in 
addition to any HTTP user authentication credentials -- to help in 
implementing such policy. 


If the client’s certificate was issued by the EST CA, and it includes 
the id-kp-cmcRA [RFC6402] extended key usage extension, then the 
client is a Registration Authority (RA) as described in [RFC5272] and 
[RFC6402]. In this case, the EST server SHOULD apply authorization 
policy consistent with an RA client. For example, when handling 
/simpleenroll requests, the EST server could be configured to accept 
POP linking information that does not match the current TLS session 
because the authenticated EST client RA has verified this information 


when acting as an EST server (as specified in Section 3.5). More 
specific RA mechanisms are available if the EST client uses /fullcmc 
methods. 
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4. Protocol Exchange Details 


Before processing a request, an EST server determines if the client 
is authorized to receive the requested services. Likewise, the 
client determines if it will make requests to the EST server. These 
authorization decisions are described in the next two sections. 
Assuming that both sides of the exchange are authorized, then the 
actual operations are as described in subsequent sections. 


4.1. Distribution of CA Certificates 


The EST client can request a copy of the current CA certificates. 
This function is generally performed before other EST functions. 


4.1.1.  Bootstrap Distribution of CA Certificates 


It is possible that the client was not configured with an Implicit TA 
database that allows a bootstrap installation of the Explicit TA 
database as described in 4.1.3. This section describes an alternate 
method by which minimally configured EST clients can populate their 
Explicit TA database. 


If the EST client application does not specify either an Explicit TA 
database or an Implicit TA database, then the initial TLS server 


authentication and authorization will fail. The client MAY 
provisionally continue the TLS handshake to completion for the 
purposes of accessing the /cacerts or /fullcmc method. If the EST 


client continues with an unauthenticated connection, the client MUST 
extract the HTTP content data from the response (Sections 4.1.3 or 
4.3.2) and engage a human user to authorize the CA certificate using 
out-of-band data such as a CA certificate "fingerprint" (e.g., a 
SHA-256 or SHA-512 [SHS] hash on the whole CA certificate). In a 
/fullecmc response, it is the Publish Trust Anchors control (CMC 
[RFC5272], Section 6.15) within the Full PKI Response that must be 
accepted manually. It is incumbent on the user to properly verify 
the TA information, or to provide the "fingerprint" data during 
configuration that is necessary to verify the TA information. 


HTTP authentication requests MUST NOT be responded to if the server 
has not been authenticated as specified in Section 3.3.1 or if the 
optional certificate-less authentication is used as specified in 
Section 3.3.3. 


The EST client uses the /cacerts response to establish an Explicit 


Trust Anchor database for subsequent TLS authentication of the EST 
server. EST clients MUST NOT engage in any other protocol exchange 
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until after the /cacerts response has been accepted and a new TLS 
session has been established (using TLS certificate-based 
authentication). 


4.1.2. CA Certificates Request 


EST clients request the EST CA TA database information of the CA (in 
the form of certificates) with an HTTPS GET message using an 
operation path of "/cacerts". EST clients and servers MUST support 
the /cacerts function. Clients SHOULD request an up-to-date response 
before stored information has expired in order to ensure the EST CA 
TA database is up to date. 


The EST server SHOULD NOT require client authentication or 
authorization to reply to this request. 


The client MUST authenticate the EST server, as specified in 
Section 3.3.1 if certificate-based authentication is used or 
Section 3.3.3 if the optional certificate-less authentication is 
used, and check the server's authorization as given in Section 3.6, 
or follow the procedure outlined in Section 4.1.1. 


4.1.3. CA Certificates Response 


If successful, the server response MUST have an HTTP 200 response 
code. Any other response code indicates an error and the client MUST 
abort the protocol. 


A successful response MUST be a certs-only CMC Simple PKI Response, 
as defined in [RFC5272], containing the certificates described in the 
following paragraph. The HTTP content-type of 
"application/pkcs7-mime" is used. The Simple PKI Response is sent 
with a Content-Transfer-Encoding of "base64" [RFC2045]. 


The EST server MUST include the current root CA certificate in the 
response. The EST server MUST include any additional certificates 
the client would need to build a chain from an EST CA-issued 
certificate to the current EST CA TA. For example, if the EST CA is 
a subordinate CA, then all the appropriate subordinate CA 
certificates necessary to build a chain to the root EST CA are 
included in the response. 


The EST server SHOULD include the three "Root CA Key Update" 
certificates OldWithOld, OldWithNew, and NewWithOld in the response 
chain. These are defined in Section 4.4 of CMP [RFC4210]. The EST 
client MUST be able to handle these certificates in the response. 

The EST CA's most recent self-signed certificate (e.g., NewWithNew 
certificate) is self-signed and has the latest NotAfter date. If the 
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EST server does not include these in the response, then after the 
current EST CA certificate expires, the EST clients will need to be 
reinitialized with the PKI using the Bootstrap Distribution of CA 
certificates (Section 4.1.1) method, which involves user interaction. 


After out-of-band validation occurs, all the other certificates MUST 
be validated using normal [RFC5280] certificate path validation 
(using the most recent CA certificate as the TA) before they can be 
used to build certificate paths during certificate validation. 


The EST client MUST store the extracted EST CA certificate as an 
Explicit TA database entry for subsequent EST server authentication. 
The EST client SHOULD disable use of Implicit TA database entries for 
this EST server now that an Explicit TA database entry is available. 
If the client disables the Implicit TA database, and if the EST 
Server certificate was verified using an Implicit TA database entry, 
then the client MUST include the "Trusted CA Indication" extension in 
future TLS sessions [RFC6066]. This indicates to the server that 
only an EST server certificate authenticatable by the Explicit TA 
database entry is now acceptable (otherwise, the EST server might 
continue to use a server certificate that is only verifiable by a now 
disabled Implicit TA). 


The EST client SHOULD also make the CA Certificate response 
information available to the end-entity software for use when 
validating peer certificates. 


4.2. Client Certificate Request Functions 


EST clients request a certificate from the EST server with an HTTPS 


POST using the operation path value of "/simpleenroll". EST clients 
request a renew/rekey of existing certificates with an HTTP POST 
using the operation path value of "/simplereenroll". EST servers 


MUST support the /simpleenroll and /simplereenroll functions. 


It is RECOMMENDED that a client obtain the current CA certificates, 
as described in Section 4.1, before performing certificate request 
functions. This ensures that the client will be able to validate the 
EST server certificate. The client MUST authenticate the EST server 
as specified in Section 3.3.1 if certificate-based authentication is 
used or Section 3.3.3 if the optional certificate-less authentication 
is used. The client MUST verify the authorization of the EST server 
as specified in Section 3.6. 


The server MUST authenticate the client as specified in Section 3.3.2 
if certificate-based authentication is used or Section 3.3.3 if the 
optional certificate-less authentication is used. The server MUST 
verify client authorization as specified in Section 3.7. The EST 
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server MUST check the tls-unique value, as described in Section 3.5, 
if one is submitted by the client. 


The server MAY accept a certificate request for manual authorization 
checking by an administrator. (Section 4.2.3 describes the use of an 
HTTP 202 response to the EST client if this occurs.) 


4.2.1. Simple Enrollment of Clients 


When HTTPS POSTing to /simpleenroll, the client MUST include a Simple 
PKI Request as specified in CMC [RFC5272], Section 3.1 (i.e., a PKCS 
#10 Certification Request [RFC2986]). 


The Certification Signing Request (CSR) signature provides 
proof-of-possession of the client-possessed private key to the EST 
server. If the CSR KeyUsage extension indicates that the private key 
can be used to generate digital signatures, then the client MUST 
generate the CSR signature using the private key. If the key can be 
used to generate digital signatures but the requested CSR KeyUsage 
extension prohibits generation of digital signatures, then the CSR 
signature MAY still be generated using the private key, but the key 
MUST NOT be used for any other signature operations (this is 
consistent with the recommendations concerning submission of 
proof-of-possession to an RA or CA as described in 
[SP-800-57-Part-1]). The use of /fullcmc operations provides access 
to more advanced proof-of-possession methods that are used when the 
key pair cannot be used for digital signature generation (see 
Section 4.3). 


The HTTP content-type of "application/pkcs10" is used here. The 
format of the message is as specified in [RFC5967] with a Content- 
Transfer-Encoding of "base64" [RFC2045]. 


If the EST client authenticated using a previously installed 
certificate issued by a third-party CA (see Section 2.2.1), the 
client MAY include the ChangeSubjectName attribute, as defined in 
[RFC6402], in the CSR to request that the subjectName and 
SubjectAltName be changed in the new certificate. 


The EST client MAY request additional certificates even when using an 
existing certificate in the TLS client authentication. For example, 
the client can use an existing certificate for TLS client 
authentication when requesting a certificate that cannot be used for 
TLS client authentication. 
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4.2.2. Simple Re-enrollment of Clients 


EST clients renew/rekey certificates with an HTTPS POST using the 
operation path value of "/simplereenroll". 


A certificate request employs the same format as the "simpleenroll" 
request, using the same HTTP content-type. The request Subject field 
and SubjectAltName extension MUST be identical to the corresponding 
fields in the certificate being renewed/rekeyed. The 
ChangeSubjectName attribute, as defined in [RFC6402], MAY be included 
in the CSR to request that these fields be changed in the new 
certificate. 


If the Subject Public Key Info in the certification request is the 
same as the current client certificate, then the EST server renews 
the client certificate. If the public key information in the 
certification request is different than the current client 
certificate, then the EST server rekeys the client certificate. 


4.2.3. Simple Enroll and Re-enroll Response 


If the enrollment is successful, the server response MUST contain an 
HTTP 200 response code with a content-type of 
"application/pkcs7-mime". 


A successful response MUST be a certs-only CMC Simple PKI Response, 
as defined in [RFC5272], containing only the certificate that was 
issued. The HTTP content-type of "application/pkcs7-mime" with an 
smime-type parameter "certs-only" is used, as specified in [RFC5273]. 


The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616] 
error code when a problem occurs. A Simple PKI Response with an HTTP 
content-type of "application/pkcs7-mime" (see Section 4.3.2) MAY be 
included in the response data to convey an error response. If the 
content-type is not set, the response data MUST be a plaintext human- 
readable error message containing explanatory information describing 
why the request was rejected (for example, indicating that CSR 
attributes are incomplete). 


If the server responds with an HTTP [RFC2616] 202, this indicates 
that the request has been accepted for processing but that a response 


is not yet available. The server MUST include a Retry-After header 
as defined for HTTP 503 responses. The server also MAY include 
informative human-readable content. The client MUST wait at least 


the specified "retry-after" time before repeating the same request. 
The client repeats the initial enrollment request after the 
appropriate "retry-after" interval has expired. The client SHOULD 
log or inform the end-user of this event. The server is responsible 
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for maintaining all states necessary to recognize and handle retry 
operations as the client is stateless in this regard; it simply sends 
the same request repeatedly until it receives a different response 
code. All other return codes are handled as specified in HTTP 
[RFC2616]. 


If the client closes the TLS connections while waiting for the Retry- 
After time to expire, then the client initiates a new TLS connection 
and performs all applicable security checks. If the client has 
already generated a CSR that includes linking identity and POP 
information (Section 3.5), then the CSR will need to be recreated to 
incorporate the tls-unique from the new, redirected session. Note: 
the key pair need not be regenerated. These are processing and 
interface burdens on the client. EST server administrators are 
advised to take this into consideration. 


The EST client MAY also make the certificate response, and associated 
private key, available to end-entity software for use as an 
end-entity certificate. 


4.3. Full CMC 


An EST client can request a certificate from an EST server with an 
HTTPS POST using the operation path value of "/fullcmc". Support for 
the /fullcmc function is OPTIONAL for both clients and servers. 


4.3.1. Full CMC Request 


If the HTTP POST to /fullcmc is not a valid Full PKI Request, the 
server MUST reject the message. The HTTP content-type used is 
"application/pkcs7-mime" with an smime-type parameter "CMC-request", 
as specified in [RFC5273]. The body of the message is the binary 
value of the encoding of the PKI Request with a 
Content-Transfer-Encoding of "base64" [RFC2045]. 


4.3.2. Full CMC Response 


If the enrollment is successful, the server response MUST include an 
HTTP 200 response code with a content-type of 
"application/pkcs7-mime" as specified in [RFC5273]. The response 
data includes either the Simple PKI Response with an smime-type 
parameter of "certs-only" or the Full PKI Response with an smime-type 
parameter "CMC-response", as specified in Section 3.2.1 of [RFC5751]. 
The body of the message is the binary value of the encoding of the 
PKI Response with a Content-Transfer-Encoding of "base64" [RFC2045]. 
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When rejecting a request, the server MUST specify either an HTTP 4xx 
error or an HTTP 5xx error. A CMC response with the content-type of 
"application/pkcs7-mime" MUST be included in the response data for 
any CMC error response. 


All other return codes are handled as specified in Section 4.2.3 or 
HTTP [RFC2616]. For example, a client interprets an HTTP 404 or 501 
response to indicate that this service is not implemented. 


4.4.  Server-Side Key Generation 


An EST client may request a private key and associated certificate 
from an EST server using an HTTPS POST with an operation path value 
of "/serverkeygen". Support for the /serverkeygen function is 
OPTIONAL. 


A client MUST authenticate an EST server, as specified in 

Section 3.3.1 if certificate-based authentication is used or 
Section 3.3.3 if the optional certificate-less authentication is 
used, and check the server's authorization as given in Section 3.6. 


The EST server MUST authenticate the client, as specified in 

Section 3.3.2 if certificate-based authenticated is used or 

Section 3.3.3 if the optional certificate-less authentication is 
used, and check the client's authorization as given in Section 3.7. 
The EST server applies whatever authorization or logic it chooses to 
determine if the private key and certificate should be provided. 


Cipher suites that have a NULL confidentiality algorithm MUST NOT be 
used as they will disclose the contents of an unprotected private 
key. 


Proper random number and key generation [RFC4086] is a server 
implementation responsibility, and server archiving of generated keys 
is determined by CA policy. The key pair and certificate are 
transferred over the TLS session. The cipher suite used to return 
the private key and certificate MUST offer confidentiality 
commensurate with the private key being delivered to the client. 


The EST client MAY request additional certificates even when using an 
existing certificate in the TLS client authentication. For example, 
the client can use an existing certificate for TLS client 
authentication when requesting a certificate that cannot be used for 
TLS client authentication. 
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4.4.1. Server-Side Key Generation Request 


The certificate request is HTTPS POSTed and is the same format as for 
the "/simpleenroll" and "/simplereenroll" path extensions with the 
same content-type and transfer encoding. 


In all respects, the server SHOULD treat the CSR as it would any 
enroll or re-enroll CSR; the only distinction here is that the server 
MUST ignore the public key values and signature in the CSR. These 
are included in the request only to allow re-use of existing 
codebases for generating and parsing such requests. 


If the client desires to receive the private key with encryption that 
exists outside of and in addition to that of the TLS transport used 
by EST or if server policy requires that the key be delivered in such 
a form, the client MUST include an attribute in the CSR indicating 
the encryption key to be used. Both symmetric and asymmetric 
encryption are supported as described in the following subsections. 
The client MUST also include an SMIMECapabilities attribute 
([RFC2633], Section 2.5) in the CSR to indicate the key encipherment 
algorithms the client is willing to use. 


It is strongly RECOMMENDED that the clients request that the returned 
private key be afforded the additional security of the Cryptographic 
Message Syntax (CMS) EnvelopedData in addition to the TLS-provided 
security to protect against unauthorized disclosure. 


4.4.1.1. Requests for Symmetric Key Encryption of the Private Key 


To specify a symmetric encryption key to be used to encrypt the 
server-generated private key, the client MUST include a 
DecryptKeyIdentifier attribute (as defined in Section 2.2.5 of 
[RFC4108]) specifying the identifier of the secret key to be used by 
the server to encrypt the private key. While that attribute was 
originally designated for specifying a firmware encryption key, it 
exactly mirrors the requirements for specifying a secret key to 


encrypt a private key. If the server does not have a secret key 
matching the identifier specified by the client, the request MUST be 
terminated and an error returned to the client. Distribution of the 


key specified by the DecryptKeyIdentifier to the key generator and 
the client is outside the scope of this document. 
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4.4.1.2. Requests for Asymmetric Encryption of the Private Key 


To specify an asymmetric encryption key to be used to encrypt the 
server-generated private key, the client MUST include an 
AsymmetricDecryptKeyIdentifier attribute. The 
AsymmetricDecryptKeyIdentifier attribute is defined as: 


id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { 
id-aa 54 } 


The asymmetric-decrypt-key-identifier attribute values have ASN.1 
type AsymmetricDecryptKeyIdentifier (where ASN.1 is defined in 
[X.680]) :: 


AsymmetricDecryptKeyIdentifier ::- OCTET STRING 


If the server does not have a public key matching the identifier 
Specified by the client, the request MUST be terminated and an error 
returned to the client. Distribution of the key specified by the 
AsymmetricDecryptKeyIdentifier to the key generator and the client is 
outside the scope of this document. If the key identified is bound 
to an X.509 certificate, then the key MUST either explicitly support 
keyTransport or keyAgreement or its use MUST be unrestricted. 


4.4.2. Server-Side Key Generation Response 


If the request is successful, the server response MUST have an HTTP 
200 response code with a content-type of "multipart/mixed" consisting 
of two parts: one part is the private key data and the other part is 
the certificate data. 


The format in which the private key data part is returned is 
dependent on whether the private key is being returned with 
additional encryption on top of that provided by TLS. 


If additional encryption is not being employed, the private key data 
MUST be placed in an "application/pkcs8". An "application/pkcs8" 
part consists of the base64-encoded DER-encoded [X.690] 
PrivateKeyInfo with a Content-Transfer-Encoding of "base64" 
[RFC2045]. 


If additional encryption is being employed, the private key is placed 
inside of a CMS SignedData. The SignedData is signed by the party 
that generated the private key, which may or may not be the EST 
server or the EST CA. The SignedData is further protected by placing 
it inside of a CMS EnvelopedData, as described in Section 4 of 
[RFC5958]. The following list shows how the EncryptedData is used, 
depending on the type of protection key specified by the client. 
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o If the client specified a symmetric encryption key to protect the 
server-generated private key, the EnvelopedData content is 
encrypted using the secret key identified in the request. The 
EnvelopedData RecipientInfo field MUST indicate the key-encryption 
kekri key management technique. The values are as follows: 
version is set to 4, key-encryption key identifier (kekid) is set 
to the value of the DecryptKeyIdentifier from Section 4.4.1.1; 
keyEncryptionAlgorithm is set to one of the key wrap algorithms 
that the client included in the SMIMECapabilities accompanying the 
request; and encryptedKey is the encrypted key. 


o If the client specified an asymmetric encryption key suitable for 
key transport operations to protect the server-generated private 
key, the EnvelopedData content is encrypted using a randomly 
generated symmetric encryption key. The cryptographic strength of 
the symmetric encryption key SHOULD be equivalent to the client- 
Specified asymmetric key. The EnvelopedData RecipientInfo field 
MUST indicate the KeyTransRecipientInfo (ktri) key management 
technique. In KeyTransRecipientInfo, the RecipientIdentifier 
(rid) is either the subjectKeyIdentifier copied from the attribute 
defined in Section 4.4.1.2 or the server determines an associated 
issuerAndSerialNumber from the attribute; version is derived from 
the choice of rid [RFC5652], keyEncryptionAlgorithm is set to one 
of the key wrap algorithms that the client included in the 
SMIMECapabilities accompanying the request, and encryptedKey is 
the encrypted key. 


o If the client specified an asymmetric encryption key suitable for 
key agreement operations to protect the server-generated private 
key, the EnvelopedData content is encrypted using a randomly 
generated symmetric encryption key. The cryptographic strength of 
the symmetric encryption key SHOULD be equivalent to the client- 
Specified asymmetric key. The EnvelopedData RecipientInfo field 
MUST indicate the KeyAgreeRecipientInfo (kari) key management 
technique. In the KeyAgreeRecipientInfo type, version, 
originator, and user keying material (ukm) are as in [RFC5652], 
and keyEncryptionAlgorithm is set to one of the key wrap 
algorithms that the client included in the SMIMECapabilities 
accompanying the request. The recipient's key identifier is 
either copied from the attribute defined in Section 4.4.1.2 to 
subjectKeyIdentifier or the server determines an 
IssuerAndSerialNumber that corresponds to the value provided in 
the attribute. 


In all three additional encryption cases, the EnvelopedData is 
returned in the response as an "application/pkcs7-mime" part with an 
smime-type parameter of "server-generated-key" and a Content- 
Transfer-Encoding of "base64". 
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The certificate data part is an "application/pkcs7-mime" and exactly 
matches the certificate response to /simpleenroll. 


When rejecting a request, the server MUST specify either an HTTP 4xx 
error or an HTTP 5xx error. If the content-type is not set, the 
response data MUST be a plaintext human-readable error message. 


4.5. CSR Attributes 


CA policy may allow inclusion of client-provided attributes in 
certificates that it issues, and some of these attributes may 
describe information that is not available to the CA. In addition, a 
CA may desire to certify a certain type of public key and a client 
may not have a priori knowledge of that fact. Therefore, clients 
SHOULD request a list of expected attributes that are required, or 
desired, by the CA in an enrollment request or if dictated by local 
policy. 


The EST server SHOULD NOT require client authentication or 
authorization to reply to this request. 


Requesting CSR attributes is optional, but clients are advised that 
CAs may refuse enrollment requests that are not encoded according to 
the CA's policy. 


4.5.1. CSR Attributes Request 


The EST client requests a list of CA-desired CSR attributes from the 
CA by sending an HTTPS GET message to the EST server with an 
operations path of "/csrattrs". 


4.5.2. CSR Attributes Response 


If locally configured policy for an authenticated EST client 
indicates a CSR Attributes Response is to be provided, the server 
response MUST include an HTTP 200 response code. An HTTP response 
code of 204 or 404 indicates that a CSR Attributes Response is not 
available. Regardless of the response code, the EST server and CA 
MAY reject any subsequent enrollment requests for any reason, e.g., 
incomplete CSR attributes in the request. 
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Responses to attribute request messages MUST be encoded as the 
content-type of "application/csrattrs" with a 
Content-Transfer-Encoding of "base64" [RFC2045]. The syntax for 
application/csrattrs body is as follows: 


CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID 
AttrOrOID ::- CHOICE (oid OBJECT IDENTIFIER, attribute Attribute } 
Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE { 


type ATTRIBUTE. &id({IO0Set}), 
values SET SIZE(1..MAX) OF ATTRIBUTE. &Type({IOSet}{@type}) } 


An EST server includes zero or more OIDs or attributes [RFC2986] that 
it requests the client to use in the certification request. The 
client MUST ignore any OID or attribute it does not recognize. When 
the server encodes CSR Attributes as an empty SEQUENCE, it means that 
the server has no specific additional information it desires ina 
client certification request (this is functionally equivalent to an 
HTTP response code of 204 or 404). 


If the CA requires a particular crypto system or use of a particular 
signature scheme (e.g., certification of a public key based on a 
certain elliptic curve, or signing using a certain hash algorithm) it 
MUST provide that information in the CSR Attribute Response. If an 
EST server requires the linking of identity and POP information (see 
Section 3.5), it MUST include the challengePassword OID in the CSR 
Attributes Response. 


The structure of the CSR Attributes Response SHOULD, to the greatest 
extent possible, reflect the structure of the CSR it is requesting. 
Requests to use a particular signature scheme (e.g. using a 
particular hash function) are represented as an OID to be reflected 
in the SignatureAlgorithm of the CSR. Requests to use a particular 
crypto system (e.g., certification of a public key based on a certain 
elliptic curve) are represented as an attribute, to be reflected as 
the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type 
indicating the algorithm and the values indicating the particular 
parameters specific to the algorithm. Requests for descriptive 
information from the client are made by an attribute, to be 
represented as Attributes of the CSR, with a type indicating the 
[RFC2985] extensionRequest and the values indicating the particular 
attributes desired to be included in the resulting certificate's 
extensions. 


The sequence is Distinguished Encoding Rules (DER) encoded [X.690] 
and then base64 encoded (Section 4 of [RFC4648]). The resulting text 
forms the application/csrattr body, without headers. 


Pritikin, et al. Standards Track [Page 36] 


RFC 7030 EST October 2013 


For example, if a CA requests a client to submit a certification 
request containing the challengePassword (indicating that linking of 
identity and POP information is requested; see Section 3.5), an 
extensionRequest with the Media Access Control (MAC) address 
([RFEC2307]) of the client, and to use the secp384rl elliptic curve 
and to sign with the SHA384 hash function. Then, it takes the 
following: 


OID: challengePassword (1.2.840.113549.1.9.7) 


Attribute: type = extensionRequest (1.2.840.113549.1.9.14) 
value = macAddress (1.3.6.1.1.1.1.22) 


Attribute: type - id-ecPublicKey (1.2.840.10045.2.1) 
value = secp384r1 (1.3.132.0.34) 


OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3) 
and encodes them into an ASN.1 SEQUENCE to produce: 
30 41 06 09 2a 86 48 86 £7 Od 01 09 07 30 12 06 07 2a 86 48 ce 3d 
02 01 31 07 06 05 2b 8104 00 22 30 16 06 09 2a 86 48 86 f7 Od 01 


09 0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03 
03 


and then base64 encodes the resulting ASN.1 SEQUENCE to produce: 


MEEGCSqGSIb3DOEJBzASBgcqhkjOPOIBMOCGBSuBBAAiMBYGCSqGSIb3DOEJDjEJ 
BgcrBgEBAQEWBggqhkjOPQODAw-- 


IANA Considerations 


Section 4.4.1.2 defines an OID that has been registered in an arc 
delegated by the IANA to the PKIX working group. 


IANA has registered the following: 


IANA updated the well-known URI registry with the following filled-in 
template from [RFC5785]. 


URI suffix: est 


Change controller: IETF 
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IANA has updated the "Application Media Types" registry with the 
following filled-in templates from [RFC6838]. 


The media subtype for CSR attributes in a CSR Attributes Response is 
application/csrattrs. 


Type name: application 

Subtype name: csrattrs 

Required parameters: None 

Optional parameters: None 

Encoding considerations: binary; 

Security Considerations: 
Clients request a list of attributes that servers wish to be in 
certification requests. The request/response is normally done 
in a TLS-protected tunnel. 

Interoperability considerations: None 


Published specification: This memo. 


Applications which use this media type: Enrollment over Secure 
Transport (EST) 


Additional information: 
Magic number(s): None 
File extension: .csrattrs 

Person & email address to contact for further information: 
Dan Harkins <dharkins@arubanetworks.com> 

Restrictions on usage: None 

Author: Dan Harkins <dharkins@arubanetworks.com> 

Intended usage: COMMON 


Change controller: The IESG <iesg@ietf.org> 
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The application/pkcs7-mime content-type defines the optional 
"smime-type" parameter [RFC5751] with a set of specific values. This 
document adds another value, "server-generated-key", as the parameter 
value for Server-side Key Generation Response. 


6. Security Considerations 


Support for Basic authentication, as specified in HTTP [RFC2617], 
allows the server access to a client's cleartext password. This 
provides support for legacy username/password databases but requires 
exposing the plaintext password to the EST server. Use of a PIN or 
one-time password can help mitigate such exposure, but it is 
RECOMMENDED that EST clients use such credentials only once to obtain 
a client certificate (that will be used during future interactions 
with the EST server). 


When a client uses the Implicit TA database for certificate 
validation (see Section 3), then authorization proceeds as specified 
in Section 3.6.2. In this situation, the client has validated the 
server as being a responder that is certified by a third party for 
the URI configured, but it cannot verify that the responder is 
authorized to act as an RA for the PKI in which the client is trying 
to enroll. Clients using an Implicit Trust Anchor database are 
RECOMMENDED to use only TLS-based client authentication (to prevent 
exposing HTTP-based client authentication information). It is 
RECOMMENDED that such clients include "Linking Identity and POP 
Information" (Section 3.5) in requests (to prevent such requests from 
being forwarded to a real EST server by a man in the middle). It is 
RECOMMENDED that the Implicit Trust Anchor database used for EST 
server authentication be carefully managed to reduce the chance of a 
third-party CA with poor certification practices from being trusted. 
Disabling the Implicit Trust Anchor database after successfully 
receiving the Distribution of CA certificates response 

(Section 4.1.3) limits any vulnerability to the first TLS exchange. 


Certificate-less TLS cipher suites that maintain security and perform 
the mutual authentication necessary for enrollment have the following 
properties: 


o the only information leaked by an active attack is whether or not 
a single guess of the secret is correct. 


o any advantage an adversary gains is through interaction and not 
computation. 


o it is possible to perform countermeasures, such as exponential 


backoff after a certain number of failed attempts, to frustrate 
repeated active attacks. 
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Using a certificate-less cipher suite that does not have the 
properties listed above would render the results of enrollment void 
and potentially result in certificates being issued to 
unauthenticated and/or unauthorized entities. 


When using a certificate-less TLS cipher suite, the shared secret 
used for authentication and authorization cannot be shared with an 
entity that is not a party to the exchange: someone other than the 
client and the server. Any additional sharing of secrets voids the 
security afforded by a certificate-less cipher suite. Exposure of a 
shared secret used by a certificate-less cipher suite to a third 
party enables client impersonation that can result in corruption of a 
client's trust anchor database. 


TLS cipher suites that include " EXPORT " and " DES " in their names 
MUST NOT be used. These ciphers do not offer a sufficient level of 
protection; 40-bit crypto in 2013 doesn't offer acceptable 
protection, and the use of DES is deprecated. 


As described in CMC, Section 6.7 of [RFC5272], "For keys that can be 
used as signature keys, signing the certification request with the 
private key serves as a POP on that key pair". The inclusion of tls- 
unique within the certification request links the proof-of-possession 
to the TLS proof-of-identity by enforcing that the POP operation 
occurred while the TLS session was active. This implies to the 
server that the authenticated client currently has access to the 
private key. If the authenticated client is known to have specific 
capabilities, such as hardware protection for authentication 
credentials and key storage, this implication is strengthened but not 
proven. 


The server-side key generation method allows keys to be transported 
over the TLS connection to the client without any application-layer 
protection. The distribution of private key material is inherently 
risky. Private key distribution uses the encryption mode of the 
negotiated TLS cipher suite. Keys are not protected by preferred key 
wrapping methods such as AES Key Wrap [RFC3394] or as specified in 
[RFC5958] as encryption of the private key beyond that provided by 
TLS is optional. It is RECOMMENDED that EST servers not support this 
operation by default. It is RECOMMENDED that clients not request 
this service unless there is a compelling operational benefit. Use 
of an Implicit Trust Anchor database is NOT RECOMMENDED when 
server-side key generation is employed. The use of an encrypted CMS 
Server-Side Key Generation Response is RECOMMENDED. 


Regarding the CSR attributes that the CA may list for inclusion in an 
enrollment request, there are no real inherent security issues with 
the content being conveyed, but an adversary who is able to interpose 
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may want, include attributes that a 
meaningless other attributes that a 
ASN.1 encoding rules DER and 
structure, 
length fields that can cause buffer 


(e.g., 


encoding rules allow for arbitrary levels of nesting, 


October 2013 


exclude attributes that a server 
Server may not want, and render 
server may want. 


BER) have a type-length-value 


and it is easy to construct malicious content with invalid 


overrun conditions. ASN.1 
which may make 


it possible to construct malicious content that will cause a stack 


overflow. 


Interpreters of ASN.1 structures should be aware of these 


issues and should take appropriate measures to guard against buffer 


overflows and stack overruns in particular, 


general. 
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Appendix A. Operational Scenario Example Messages 


A. 


L 


(Informative) 


This section expands on the Operational Scenario Overviews by 
providing detailed examples of the messages at each TLS layer. 


Obtaining CA Certificates 


The following is an example of a valid /cacerts exchange. 


2013 


During the initial TLS handshake, the client can ignore the optional 
server-generated "certificate request" and can instead proceed with 


the HTTP GET request: 


GET /.well-known/est/cacerts HTTP/1.1 

User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 Opens 
SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 

Host: 192.0.2.1:8085 

Accept: */* 


In response, the server provides the current CA certificates: 


HTTP/1.1 200 OK 

Status: 200 OK 

Content-Type: application/pkcs7-mime 
Content-Transfer-Encoding: base64 
Content-Length: 4246 


MIIMOQYJKOZIhvcNAQCCOIIMKjCCDCYCAQEXxADALBgkqhkiG9wOBBwGgggwMMIIC 
TZCCAeOgAwIBAgIJAJpY3nUZO3qcMAOGCSqGSIb3DQEBBQUAMBSxGTAXBgNVBAMT 
EGVzdEVAYWl1wbGVDOSBPd08wHhcNMTMwNTA5MDMIMzMxWhcNMTQwWNTA5MDM1MzMx 
WjADbMRkwFwYDVQODExBlC3RFeGFtcGxlQO0EgT3dPMIIBIjANBgkqhkiG9wOBAQEF 
AAOCAQ8AMIIBCgKCAOEAwDqpiHopalCubpRqbpEN7LqTIqWELFIA9qDDheHIKuyO 
HW/ZAP7Rl14S5ZU6gaLW/ksseBUxdmox3KNyvtyjehIofTu28eZWhgy6/LCEGWR3P 
K-fgPBAOl0JfJR/8oeXZa700LVQc3hI4kCeqjFMs-*biYHOvp/RluhftyZ5kzQyHl 
EGSRkwl/qUKkTZ8PCF8VFlYfqmUoqsaRTyZbjIIA4J-*Y6/jEG*p7QreW9zcz4sPe8 
3c/uhwMLOWQkZtKsQtgo5CpfYMjuAmk4Q2joQq2vcxlc-WNKHf-t*wbrDbllORZril 
9ISlI940umcRz3uBGlYg7z83hdDfasmdfbp8gOSNFOIDAQABOO0IWODAPBgNVHRMB 
Af8bEBTADAOH/MBOGA1UdDgOWBBOITTKxMqATXrfcA4ffpCIbt6Gsz0jAOBgNVHQ8B 
Af8EBAMCAQYwDQYJKOZIhvcNAQEFBOADggEBACPnQPu5WReUGuCMSOnBOGa2tXh6 
uZPAmS3JlqEfDePam/IiU9ssyYdcDwhVvKMoPAgI/yu4XFqhdpIoy/PyDAT15MT7 
KADCxXkh5rM1IgMui7FvBKLWYGdy9sjEf90wAkBjHBe/TMO1NNw3uELyONSkHIvO 
X0pu6aPmm/moIMyGi46niFseliWlXXldGLkOQsh0e7U-c-wpBXO7QpOr2KB2-4Yf-tuA 
KYlSWzEG23bUxXlvcbUMgANDGj5r6z-*niKLOVlApip/iCuVEEOCZ91UlmJjVLQWA 
x6ietv840MtpIojiGMOCAXWCVlKKEgcMOsN3S41vm8PtpqOGLoIJY8NTD20wggMD 
MIIB66ADAgECAgEBMAO0GCSqGSIb3DQEBBQUAMBSxGTAXBgNVBAMTEGVzdEVAYWlw 
bGVDOSBPdO8wHhcNMTMwNTA5MDM1MzMyWhcNMTOWNTA5MDM1MzMyWjADMRkwFEwYD 
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VOODEXBIC3RFeGFtcGxlQOEgTndPMIIBIjANBgkqhkiG9wOBAQEFAAOCAQ8AMIIB 
CgKCAQEAnn3rZ3rMJHwf7MD9KAmubxHAvtdnrsQf5OfgtMhRILA4aePNhAdgPy j8C 
loxOgD3UTV-tdOlViOzVxPN7acikoOnkIdRpjpOpkyMo-KkvHMOXGnQOTbsMAv1qWt 
9S12DMpo0GOAle4Ge3ud5YPOTR/q6PvjN51IEwYKksG7CglwZwBt5JbwhYr2D/0u 
btGltriRVixPWrvt-twz/ITp5rcjh/8RS3LE8tQy3kTNhJF3Y/esR2sSgOiPNgIto 
CATysbaINEPr4MemgMLAtDpR/aG9y*8Qe7sl1LyMFvDletp2mmBykAC/"7nOat/pwU 
1B0sN524D1XAgz8ZKvWrkh+ZaO0Or3hwIDAQABol1 IwUDAOBgNVHO8BAf 8EBAMCBLAW 
HOYDVROOBBYEFLHEaeZbowSn2Jejizu/uWqyMkI8MB8GAlUdIwQYMBaAFAhNMrEy 
oBNet9zh9-*kIhu3oazPSMAO0GCSqGSIb3DOQEBBQUAAAIBAQCLDkL7aLNV6hSOkIqH 
qt*shV9YLO56/tj00vY/jV5skgDHk5d0B4*OGortKVuGa57-*tvOavTrlJns3bNW8Ntv 
zkDEhmd00Ak02aPsi4wRHLFgttUf9HdEHAuTkAESPTUA43DiptjkfHhtBMfsFrCkd 
sxWzCz+prDOMHY fUEKHRVV++1zyGEX6ov1lAp21U2p3E+ASihL/amxTEQAsbwjUTI 
R52zoL6nMPzpbKeZi2MOeEBVF8sDueA9Hjo6woLjgJqV0/yc5vC2HAxUOhxOcWTY 
GcRBgL/yOyQLKiY5TKBH9510jO4vhF2HmcoO7DkcNLYJOgel6ssx4ogBHul20VgF 
XJJjMIIDAzCCAeugAwIBAgIBAjANBgkqhkiG9wOBAQUFADADMRkwFwYDVQODEXxBlI 
C3RFeGFtcGxlQOEgTndOMBA4XDTEZzMDUwOTAZzNTMzMlOXDTEOMDUWwOTAZzNTMzMlow 
GzEZMBCGA1UEAxMOZXNORXhhbXBSsZUNBIE93TjCCASIwDQYJKOZIhvcNAQEBBOAD 
ggEPADCCAQoCggEBAMA6qYh6KWiArm6Uam6RDey6kyKlhCxSAPagwA4XhyCrsjhlv 
20D-0ZeEuWVOoGilv5LLHgVMXZqgMdyjcr7co3oSKH07tvHmVoYMuvywhBlkdzyvn 
4DWONJdCXyUf/KH12Wu9KClUHNASOJAnqgoxTLPm4mB9L6f0ZboX7cmeZMOMh9RBr 
EZMNf61CpE2fDwhfFRZWHO6plKKrGkU8mW4yCOCfmOv4xBvqeOK3l1vc3M-*LD3vN3P 
"7ocDCzlkJGbSrELYKOOqX2DI7gJpOENO6EKtr3MZXP1jSh3/sG6w29dTkWa4pfSE 
pSPeKLpnEc97gRtWIO8/NAXQ32rJnX26fIDkjRUCAWEAAaNSMFAwDgYDVROPAQH/ 
BAOQDAgSwMBOGA1UGDgOWBBOITTKxMqATXrfcA4ffpCIbt6GszOjAfBgNVHSMEGDAW 
gBSxxGnmW6MEp9iXo4s7v7lqsjJCPDANBgkqhkiG9wOBAQUFAAOCAQEALhDaE6Mp 
BINBsJozdbXlijrWxL1CSv8f4GwpUFk3CgZjibt/qW9UoaNRAE58yRopuEhjwFZK 
2w8YtRqx8lZoFhcoLkpBDfgLLwhoztzbYvOVKOMidjBlkBEVNR5MWdrs7F/AxWuy 
iZ2-8AnR8GwqEIbCDOA7xIghmWEMh/BVI9C7GLqd6PxKrTAjuDfEpfdWhU/uYKmK 
cL3XDbSwr30j2EQyaTV/3WOTn2UfuxdwDQ4ZJs9G*Mw50s 7AG6CpISyOIFmX6/bU 
DpJXGLiLwfJ9C/aum9nylYuGCJ68BuTrCs9567KGfXEXIOmdFFCL7TaVRA43kjsg3 
c43kZ7369MeEZzCCAvswggH joAMCAQICCODprp3DmjOyETANBgkqhkiG9w0BAQUF 
ADAbMRkwFWwYDVQQDEXxB1c3RFeGFtcGx1lQ0EgTndOMB4XDTEZMDUWOTAZNTMzM10X 
DTEOMDUwOTAzNTMzMlowGzEZMBCGA1UEAxMQZXNORXhhbXBsZUNBIE53TjCCASIw 
DOYJKoZIhvcNAQEBBOQADggEPADCCAQoCggEBAJ5962d6zCR8H-*zA/SuJrm8RwL7X 
Z67EH+Tn4LTIUSC+Gn jzYQHYD80/ApaMToA91E1fnUNVY jslcTze2nIpKDp5CHUa 
Y6TqZMjKPipLxzEFxp0OE27DAL9alrfUtdgzKaNBjgNXuBnt7neWDzk0f6uj74zed 
SBMGCpLBuwoJcGcAfuSW81IWK9g/9Lm7Rpba4kVYsTl1q77fsM/yE6ea314f/EUtyx 
PLUMt5EzYSRd2P3rEdrEoDojzYCLaAgE8rG2iDRD6-*DHpqjC-*LO6Uf2hvcvvEHu 
NS8jBbw5XradppgcpAAv-45zmrf6cFJQdLDeduA9VwIM/GSrlq5IfmWjq94cCAwEA 
AaNCMEAwDwYDVROTAQH/BAUWAWEB /zAdBgNVHOAEFgQUscRp5lujBKfYl160LO7-45 
arlIyQjwwDgYDVROPAOH/BAQDAgEGMAOGCSqGSIDb3DQEBBQUAAAIBAQBCz/CWdYvn 
GM/SdCdEiom5AlVxaW8nKgCWg/EyWtAIiaHQuViB-jTUAE91ona2MbJoFHW8U5e8 
9dCPOrJpA9UYXXhWvFOzd5ZWpms4wUYtlij3gqqd36KorJIAuPigVngl3yKytxM7c 
VmxOnh0aux3aEnEyRGAhGalHpORaKdgPRzUaGtipJTNBkSV5SAkDAyDCPHMNbBu-* 
OcluerwEpbz6GvE7CpX12jrTBZSqBsFelq0iz4kk9t*t*9CnwZwrVgdzklhRfJ1Z4;j 
NkLruwbQ+o4NvBZsXikKxNfn3K203SK8AuaEyDWkq18+5rjcfprRO8x4YTW+6mxPq 
jJMOMAGNDEW+10QAxAA== 
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A.2. CSR Attributes 


The following is an example of a valid /csrattrs exchange. During 
this exchange, the EST client authenticates itself using an existing 
certificate issued by the CA for which the EST server provides 
services. 


The initial TLS handshake is identical to the enrollment example 
handshake. The HTTP GET request: 


GET /.well-known/est/csrattrs HTTP/1.1 

User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS 
SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 

Host: 192.0.2.1:8085 

Accept: */* 


In response, the server provides suggested attributes that are 
appropriate for the authenticated client. In this example, the EST 
server also includes two example attributes that the client would 
ignore unless the attribute type is known to the client: 


HTTP/1.1 200 OK 

Status: 200 OK 

Content-Type: application/csrattrs 
Content-Transfer-Encoding: base64 
Content-Length: 171 


MHwGBysGAQEBARYwIgYDiDcBMRsTGVBhcnN1IFNFVCBhcyAyLjk50S4xIGRhdGEG 
CSqGSIb3DQEJBzAsBgOINwIxJQYDiDcDBgOINwOTGVBhcnNLIFNFVCBhcyAyLjk5 
OS4yIGRhdGEGCSskAwMCCAEBCWYJYIZIAWUDBAIC 


A.3. Enroll/Re-enroll 


The following is an example of a valid /simpleenroll exchange. The 
data messages for /simplereenroll are similar. 


During this exchange, the EST client uses an out-of-band distributed 
username/password to authenticate itself to the EST server. This is 
the normal HTTP WWW-Authenticate behavior and is included here for 
informative purposes. When an existing TLS client certificate is 
used, the server might skip requesting the HTTP WWW-Authenticate 
header, such as during a /simplereenroll operation. 


During the initial TLS handshake, the client can ignore the optional 


server-generated "certificate request" and can instead proceed with 
the HTTP POST request. In response to the initial HTTP POST attempt, 
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the server requests WWW-Authenticate from the client (this might 
occur even if the client used a client certificate, as detailed in 
the normative text above): 


HTTP/1.1 401 Unauthorized 

Content-Length: 0 

WWW-Authenticate: Digest qop-"auth", realm="estrealm", 
nonce="1368141352" 


In the subsequent HTTP POST, the username/password is included, along 
with the complete application/pkcs10 content: 


POST /.well-known/est/simpleenroll HTTP/1.1 

Authorization: Digest username-"estuser", realm-"estrealm", nonc 
e-"1368141352", uri-"/.well-known/est/simpleenroll", cnonce="M 
TYwMzg3", nc-00000001, qop-"auth", response-"144cc27f96046f1d70e 
b16db20f75f22" 

Host: 192.0.2.1:8085 

Accept: */* 

Content-Type: application/pkcs10 

Content-Transfer-Encoding: base64 

Content-Length: 882 


MIIChTCCAWOCAQAwHzEGdMBSGA1UEAxMUZGVtb3NOZXAOIDEzNjgxNDEzNTIwggEi 
MAOGCSqGS Ib3DQEBAQUAA4 IBDwAwggEKAoIBAOCINp+kdz+Nj8XpEp9kaumWxDZ3 
eFYJpQKz9ddD5e5OzUeCm103ZIXQIxcOeVtMCatnRr3dnZRCAxGjwbqoB3eKt29/ 
XSOffVvctodbywOWdkQOIbntCQry8YdcBZ-4*8LjI/N7M2krmjmoSLmLwU2VA4A4aNKfOY 
MLR5Krmah3Ik31jmYCSvwInv6mx6pr2pTJ82JavhTEIIt/fAYqlRYhkM1CXOBL-ty 
hEoDanN7TzC94skf£S3VV-f53J9SkUxTYcylRwOKk3VXfxWwy-t*cSKEPREl716kOYeK 
tDEVAgBIEYM/L1S69RXTLujirwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4APAgMB 
AAGgITAfBgkqhkiG9wOBCOCxEhMOK3JyO2l1yLzcrRV11NTBUNDANBgkqhkiG9w0B 
AQUFAAOCAQEARBvOAJeXaHpll1MFIdzWqoildOCf6U-*qaYWCBzpLADvJrPKlqx5pq 
wXM830A10-*7RvrFvtnyd6VF2rl/MrNp*ISKuA9LYWIBjVe/LXoBO8dB/KxrYll6c 
VUS+Yydilm/a+DaftYSRGolMLtWeiqbc2SDBr2kHXW1TR130hIcpwmr29kC2Kzur 
5thsuj276FGL1vPuO0dRfGOQfx4AWWa9uAHBgz6tW37CepZsrUKe/O0pfVhr20HxApYh 
cHGBODOHVTFV jHccaUjAXicrtbsVhU5ollPv7f4l1EApv3SBOmJcaq50832BzHw/n 
PyMFCM15E9gtUVee5C62bVwuk/tbnGsbwQ-- 
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The EST server uses the username/password to perform 
authentication/authorization and responds with the issued 
certificate: 


HTTP/1.1 200 OK 

Status: 200 OK 

Content-Type: application/pkcs7-mime; smime-type-certs-only 
Content-Transfer-Encoding: base64 

Content-Length: 1122 


MIIDOAYJKOZIhvcNAQCCOIIDKTCCAyUCAQExADALBgkqhkiG9wOBBwGgggMLMIID 
BzCCAet*gAwIBAgIBFTANBgkqhkiG9wOBAQUFADADMRkwFwYDVQODEXBlC3RFeGFt 
cGxlQO0EgTndOMBAXDTEzMDUwOTIzMTU1M1OXDTEOMDUwOTIZzMTU1M1OoWHZzEGMBSsG 
AlUEAxMUZGVtb3NOZXAOIDEzNjgxNDEzNTIwggEiMAOGCSqGSIDb3DOEBAQUAAAIB 
DwAwggEKAOIBAQCINp-tkdz-*Nj8XpEp9kaumWxDZ3eFYJpOKz9ddD5e5OzUeCm103 
ZIXQOIxcOeVtMCatnRr3dnZRCAxGjwbqoB3eKt29/XSQffVvtodbywOWdkQOIbntC 
Qry8YdcBZ*8LjI/N7M2krmjmoSLmLwU2VA4aNKfOYMLR5Krmah3Ik31jmYCSvwTnv 
6mx6pr2pTJ82JavhTEIIt/fAYql1RYhkMICXoBL-*yhEoDanN7TzC94AskfS3VV-cf£53 
J9SkUxTYcylRwOk3VXfxWwy-cSKEPREl716kOYeKtDEVAgBIEYM/L1S69RXTLuji 
rwnqSRjOquzkAkD31BE961KZCxeYGrhxaRA4PAgMBAAGjUjBOMA4GA1UGDWEB/wQE 
AwIESDAdBgNVHOAEFgQU/qDdB6ii6icQ8wGMXvyljfEA4xtUwHwYDVROjBBgwFoAU 
scRp5lujBKfYl60OLO7*5arlyOjwwDOYJKoZIhvcNAQEFBOADggEBACmxg1lhvL6-47 
at+1lFTARoxainBx5gxdZ9omSb0L+qL+4PDvg/+KHzKsDnMCrcU6M4 YP 5n0EDKmGa6 
41Y8fbET4tt7 judg6ixb95/760ThOvuctwkGr6+D6ETT£qyHnrbhxX31AhnB+0Ja7 
olgv4CWxhl1lI8aRaTXdpOHORvNOSMXdcrlCys2vrtOl-*LjR2a3kajJO6eQ5leOdzF 
OLlZfOPhaLWenOe2BLNJIOvsC2Fa*2LMCnfC38XfGALa5A8e7fNHXWZBjXZLBCza3 
rEs9MIh2CjA/ocSC/WxmMvd-Eqnt/FpggRy-*F81ZSRvBaRUCtGEl1lgDmu6AFUxce 
RAPOrT2xz8ChADEA 
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A.4. Server Key Generation 


The following is an example of a valid /serverkeygen exchange. 
During this exchange, the EST client authenticates itself using an 
existing certificate issued by the CA the EST server provides 
services for. 


The initial TLS handshake is identical to the enrollment example 
handshake. An example HTTP POSTed message is: 


POST /.well-known/est/serverkeygen HTTP/1.1 
Host: 192.0.2.1:8085 

Accept: */* 

Expect: 100-continue 

Content-Type: application/pkcs10 
Content-Transfer-Encoding: base64 
Content-Length: 963 


MIICwTCCAakCAQAwWzE-MDwGA1UEAxM1c2VydmVyS2V5R2VuIlHJlcSBieSBjbGll 
bnQgaW4gZGVtbyBzdGVwIDEyIDEzNjgxNDESNTUxGTAXBgNVBAUTEFBJRDpXaWRn 
ZXQgU046MTAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAOIBAQCVEI/6m4A/ 
3/L32Suyzbf28LM9y8COfp0aepa7o20BSfluvm8HXR44m1V+wpieM8H5n3Ub3RIo 
RUun/FllIzK9uV7UrkqJ3Yzmq2NOoTdAC-*OPsV/RPTu873dhFrssDk3PANIphlSS 
SSIkt5rhz7wYbCqCFR5Aphe/30Jx7D*xBI5Rs8e6vRS8IpuImh71BHiLfhq9AFhz 
4AZJsOUSVpUmqUogFsM7S0Q6XI14dl*djhpjT-*YTJ6hQ2PXrqdch3KsTO8c6aKste2 
5Q0Jxh708JHVlPHOAYIxXtAYSutcbbTN5TXWFCWSrWDJ-ctzuMmk2yU-*dioloW7YR7V 
ftAvazJ3l1aQbAgMBAAGgITAfBgkqhkiG9wOBCOCxEhMOZEZzQVhtSm5qb2tCdER2 
CjANBgkqhkiG9wOBAQUFAAOCAQEAR-*IOEQB-hSjrLCAjnVH6bZdHUNGszIdwxliu 
L4n-*0XK3SfEZzeOMkCAT74yFGKj3redS1Ht9atYUPDOD1Qi9Jf9Co8eLblolll19A6 
GaS7980fxIFOP1ODr6/GqjheqJEIbcDTAJqtkvDihyQ4GQnhosygIZHvKppQlebA 
gvp2RISnMroPCe 6RgTU9E2 fmI 9rin/9PyXewWFF lnamp+1lYbTGwjvlaElikhjCL1H 
veHhCdgOExPw+fqhKhH jp+0ZKBlo2bC3pqRWvDTi Zuwt 9UpFF£GtuxvpTp440S/ 4 
M/965hWIw/5dshY/wQjIfYs07bbq2ERbpJiw9bAQY34gyoVmEQ-- 
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Because the DecryptKeyIdentifier attribute is not included in this 
request, the response does not include additional encryption beyond 
the TLS session. The EST server response is: 


HTTP/1.1 200 OK 

Status: 200 OK 

Content-Type: multipart/mixed ; boundary-estServerExampleBoundary 
Content-Length: 3219 


This is the preamble. It is to be ignored, though it 

is a handy place for estServer to include an explanatory note, 
including contact or support information. 
-—-estServerExampleBoundary 

Content-Type: application/pkcs8 

Content-Transfer-Encoding: base64 


MIIEvgIBADANBgkqhkiG9wOBAQEFAASCBKgwggSkAgEAAOIBAQDPwKtwJ7T jMgA- 
Poj64V909ryql0foPI1hUAYq5y8/bOP5ZTe6ArgVhUye099ActdfdwpyP/DESiujU 
F/dS62Vck3UWNbnw-4038FUp0OenLbbjSTud48KpEW6t*FzkeuAanPGZMAlwKyrYy9 
rD5tQOOJU/CBVhUrITyYLZNYUe4agbpcROwMtrRr2E58Mu8wQ80ryk6nkL"7COk5Z 
IOQdNRxldk7DFvpA85YnlstumoGRtVLW51iXeTS1LtXwhuUb/j6Lds3vvAiJ2SiZ0 
Y3rxPlnJVyFmR8Mf2TBOjzuFqva/VLD2ayQjgaGEjq2ZWHXelQAOZ6N3lrChojEK 
FGq93yOhAgMBAAECggEBALQ5az/nYjd5x9Y3f 7NMUffwl- jRRfMHCMTRx/u4AEAO 
KBYmOhFVZZtxfMtz7xlD8GO0Th6gs2hFA6gwcIlUPmiX-*UaOLxhtOxWaLGgYmcNAm 
BiCDjLBQ7xRQCWtlcK9WCA5-HBWtcEy6244rXxh*IyWd6NT6bXCl65AECX87y/e3 
JFJ7XFNeDP656s2DmxSCcitiDte6SaEm7sJvYGul6qevJeMThcQcC9/rJjXkvpGL 
IKK2px5idad4Pb6-4QHpqj3d40M8djO6wYUvrH8XQLqAaF8Hd51FWVU57nSYY-H79 
GaNDTfRTUL6AXr7kmMsKVFOJ0JjZExUCVMZtGiqhB6UCgYEA6390tdWLZCzyZFMe 
p/7/VlRddozOVAtrU2dxnEb4cWD8Gerg8uNvp80G84gH-* 6MbPwz4ZYWKCgDFqyrAlw 
SF02n9Sovh93eoJ51latSbfeYUkLtB8L/HVk5/CBGESV9MUkdMFO-«*B43YlhyEDyKW 
£X2+0UeHLFgRrfpSzP2cXduEieMCgYEA4db/SIrwN2+g1Gj030E09kd89VGjVRer 
srbcqc7DcPXP 6Lw42sx96h4 JVWWQHVo3DfwFBdUb1LH2cnVXQjgDUHdNdpl0lcf/ 
BFYCFINi2qKMqiJYswkhYxZl1BLz/zuQTDbPFL2PgLniKFG2aFLrTS3S/tgeB5QwI 
RPigH3kfI6sCgYAPqsCJyFMIrvfRRNZdQewi4VnPSEPF4/hjpAs1gD8vfSoZWlkw 
vylUd9HCerzgYaA7rixieQOsxTvtxhL6PXl1M2NEBFQbV16hPFL6/IiGAF0u90HNO 
eG8rHtqK1SjnBn4yoYFm70Dhe7QtbZelcaAoPCH6CUHj2St5B8ZHWDCtREOKBgHNp 
wER+XIy4C2UByCANv9csaxXulIOdX1XNbaCGP fOm5dWrm5ddLMf33MO9vaSRe-tku3 
Q4nbgsGLwPplZQZt*QZNZpMi7W6306yp4GdAJ5Pbtoww/STOVqW5OB7dILyK4A9S4 
zkiNrf+Rs18GM/vsDhc9rsuDwqofIAq/VHVBHNzZJAoGBAOHQof 5L6iGHOHcxLazx 
4MGvRTpmzU/PX60Q3Q0xqpetEGFEDZAaL58L67SSS3fFBnKrVAidF611C1lbAHlaoRa 
fYHUDi45xBoroyOhBwrnTKRxppua4UK75FUH5PPJfR6cCvw5stRkzlevTZHhozkX 
pM7PYH/x4BiBmgQ3bhOqTp4H 

--estServerExampleBoundary 

Content-Type: application/pkcs7-mime; smime-type-certs-only 
Content-Transfer-Encoding: base64 
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MIIDRQYJKOZIhvcNAQCCOIIDNjCCAzICAQExADALBgkqhkiG9wOBBwGgggMYMIID 
FDCCAfygAWIBAgIBFjANBgkqhkiG9wOBAQUFADADMRkwFwYDVQODEXBlC3RFeGFt 
cGxlQO0EgTndOMBAXDTEzMDUwOTIZzMjU1NIOXDTEOMDUwOTIZzMjU1NlowLDEqMCgG 
AlUEAxMhc2VydmVyc21kZSBrZXkgZ2VuZXJhdGVkIHJlc3BvbnNl1MIIBIjANBgkq 
hkiG9wOBAQEFAAOCAQ8AMIIBCgKCAQEAz8CrcCeOA4zIAPj6Il-ruFfdPa8qpdH6D9Y 
VOGKucvP2zjt*WU3ugKA4FYVMntPfOHPnX3cKcj/wxEorolBf3UutlXJNl1FjW58PuD 
t/BVKdHpy2240k7nePCqRFuvhc5HrgGpzxmTANcCsq2Mvaw-tbUDjiVPwgVYVKyE8 
mC2TWFHuGoG6XEdMDLa0a9hOfDLvMEPNK8pOp5C-*wjpOWSEHTUCZXZOwxb6QPOWJ 
9bLbpqBkbVSludYl3k0tS7V81lb1G/4-*i3bN77wIidkomdGN68T5ZyVchZkfDH9kw 
To87har2viSw9mskI4Ghhl6tmVh13pUADmejd5awoaIxChRqvd8 joQOIDAQABolIw 
UDAOBgNVHQ8BAf8EBAMCBLAwHQYDVROOBBYEFKeZixu9F-tappDX2SS5HaxmV6Jr4 
MB8GAl1UdIwQYMBaAFLHEaeZbowSn2Jejizu/uWqyMkI8MAO0GCSqGSIb3DQEBBQUA 
AAIBAOBHhLmRAKrnTapqqBObDM9IQDOPuwW-fWlgYwZKlSm/IWIwHEZLligXhp]j]j 
rf4xqpIkiJMmkaOeoXA8PFniX0/1Z2M9FQSM/j89CUf5dMoAqWj8s17xuXu9L/hVe 
XjjXHsL40WuDG6tMPN9vcT8tE3ruor608MKSHFX/NEM6-AaNVSUPTmB33BgYBlWa 
E7pn3JMN6pjIxsHnFA4pKi8qvoTSVVjaCEwUe8Q/fwlyvjoHoYJtyMn4v5Kb3Rt-4m 
s8YieltcfVQrjQutqr34/IJsKdPziZwi92KZa*1958A6M90/p50IO0up9ZXKg2DEC 
109qTOGyYJ6SsxAyKiGTOxk6jMddDoQAxAA-- 
-—-estServerExampleBoundary-- 

This is the epilogue. It is also to be ignored. 
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